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(57) ABSTRACT 

The present invention is particularly applicable to navigation 
of Internet by two-way interactive communication mobile 
devices that are capable of wireless communication via a 
link server with service providers or network servers on the 
Internet. Despite the limited computing resources in mobile 
devices that make it economically and technically imprac- 
tical for the mobile devices to operate a local browser 
functioning as if it was in a desktop computer, the present 
invention allows the mobile devices to interact effectively 
with the Internet using a control engine operating in the link 
server and an interface engine operating in the mobile 
devices. The control engine, which utilizes the computing 
resources of the link server device, is responsible for tasks 
that require considerable computing power and memory, 
such as processing of URL requests, interpretation of 
markup language files, management of data cache and 
variable states. Further, working with a message processor in 
the server device, the control engine communicates with an 
interface engine using a compact data format that is effi- 
ciently transportable in the wireless data network. The 
interface engine typically performs tasks that do not require 
considerable computing power and memory, such as receiv- 
ing input data from users, and the rendering of the compact 
data format received from the link server device, to cause the 
mobile device to display contents in the markup language 
files on a display screen. 

49 Claims, 19 Drawing Sheets 
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METHOD AND ARCHITECTURE FOR 
INTERACTIVE TWO-WAY 
COMMUNICATION DEVICES TO INTERACT 
WITH A NETWORK 

CROSS-REFERENCE TO RELATED 
APPLICATION 

This application is a continuation-in-part of U.S. patent 
application Ser. No. 08/570,210, now U.S. Pat. No. : 5,809, 
415, entitled "METHOD AND ARCHITECTURE FOR AN 
INTERACTIVE TWO-WAY DATA COMMUNICATION 
NETWORK" by Alain Rossmann, one of the co-inventors 
hereof. 

AUTHORIZATION WITH RESPECT TO 
COPYRIGHTS 

A portion of the present disclosure contains material 
subject to copyright protection. Such material includes, but 
is not limited to, an Appendix entitled "Imp Specification 
protocols between Femto Engine and Terminal". The copy- 
right owner has no objection to the facsimile reproduction 
by anyone of the patent document or the patent disclosure, 
as it appears in the Patent and Trademark Office patent files 
or records, but otherwise reserves all copyright rights what- 
soever. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

This invention relates generally to data communications, 
and in particular to interactive two-way communication 
mobile devices that permit a user to interact with a network 
server providing hypermedia information through a data 
network. Such a data network can include, for example, the 
Internet and a wireless network. The mobile devices may 
include cellular telephones, two-way pagers, or a palm-sized 
computing devices and typically have limited computing 
resources. 

2. Description of the Related Art 

The Internet is a rapidly growing communication network 
of interconnected computers and computer networks around 
the world. Together, these connected computers form a vast 
repository of multimedia information that is readily acces- 
sible by the connected computers from anywhere at any 
time. To navigate a portion of the Internet organized as the 
"World Wide Web", the connected computers, e.g., work- 
stations and desktop computers, typically operate a user 
interface called a "browser". A browser is a client applica- 
tion program that generally requests multimedia information 
throughout the Internet using, typically, the Hypertext Trans- 
fer Protocol (HTTP). A computer which operates a browser 
using HTTP is generally a relatively powerful computer with 
sufficient computing resources, such as processing power, 
memory, a display capability and a user interface. 

To provide mobility and portability of access to the 
Internet, interactive two-way communication mobile 
devices capable of communicating, via wireless data 
networks, with the Internet have been introduced. The 
interactive two-way communication mobile devices (e.g., 
two-way pagers, cellular phones, palm-sized computing 
devices and personal digital assistants (PDAs)) are among 
the fastest emerging communication devices. These devices 
enable users to receive, collect, analyze, review and dis- 
seminate information as the users travel or move about. 
Unlike computers coupled to the Internet, the mobile 
devices are characterized by severe limitations in computing 
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resources. For example, a cellular phone has less than one 
percent processing power of a typical desktop personal 
computer, generally less than 128 kilobytes of memory, an 
LCD display which is perhaps four lines high by twelve or 

5 twenty characters, and limited or non-existent graphics 
capabilities. Further, a cellular phone inputs using a keypad 
that has far fewer keys than a typical personal computer (PC) 
keyboard. With these constraints, a mobile device cannot 
efficiently operate the browser used by desktop computers to 

10 navigate the Internet. 

To make available to mobile devices computing resources 
comparable to a desktop computer is too cosdy. There is, 
therefore, a great need for a solution that enables mobile 
devices to freely access information on the Internet without 

15 providing these computing resources in the mobile devices. 
Additionally, mobile devices are typically serviced 
through one or more wireless service carriers. The wireless 
service carriers often provide additional services by upgrad- 
ing client application programs in the mobile devices. In 

20 conventional computers, an upgrade can be accomplished by 
downloading a new version of an application program from 
a service provider. In mobile devices, downloading a new 
version of an application program can be a prohibitive task, 
limited by the performances of the computing resources and 

25 the wireless network. Hence, there is a further need for an 
ability to manage client application programs operated by 
the mobile devices. 

SUMMARY OF THE INVENTION 

30 The present invention addresses the above described 
problems and is particularly applicable to navigation of 
Internet web pages by two-way interactive communication 
mobile devices (e.g., mobile computing devices, cellular 
phones, palm-sized computer devices, personal digital assis- 

35 tant devices and Internet-capable appliance remote 
controllers) which are capable of wireless communication 
via a link server with service providers or network servers on 
the Internet. Despite the common deficiencies of mobile 
devices (i.e., a primitive processor, little memory and limited 

40 graphics capability) which make it economically and tech- 
nically impractical for the mobile devices to operate a local 
browser functioning as if it was in a desktop computer, the 
present invention allows the mobile devices to interact 
effectively with the Internet and can be used with a wide 

45 variety of wireless communication networks (e.g., cellular 
digital packet data (CDPD) network, Global System for 
Mobile Communications (GSM) network, Code Division 
Multiple Access (CDMA) network and Time Division Mul- 
tiple Access (TDMA) network). 

so According to one aspect of the present invention, a mobile 
device includes an interface engine that, via a client module, 
communicates and operates with a control engine in a link 
server device over a wireless network. The control engine, 
which utilizes the computing resources of the link server 

55 device, is responsible for tasks that require considerable 
computing power and memory, such as processing of URL 
requests, interpretation of markup language files, manage- 
ment of data cache and variable states. Further, working with 
a message processor in the server device, the control engine 

60 communicates with an interface engine using a compact data 
format that is efficiently transportable in the wireless data 
network. The interface engine typically performs tasks that 
do not require considerable computing power and memory, 
such as receiving input data from users, and the rendering of 

65 the compact data format received from the link server 
device, to cause the mobile device to display contents in the 
markup language files on a display screen. 
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According to another aspect of the present invention, 
incoming messages to the mobile device, including notifi- 
cation and requests, and which typically has one or more 
universal resource identifiers or locators, are processed in 
the link server device to generate compact messages. The 5 
link server device replaces universal resource locators in the 
incoming message with address identifiers, and manages an 
address table mapping each universal resource locator with 
an address identifier. Thus processed, the resulting compact 
messages demand less bandwidth of the wireless network, 10 
thus reducing high latency and requiring less air time. 

According to still another aspect of the present invention, 
local service requests in the mobile device are processed 
simultaneously in the interface engine and the control 
engine. In the prior art, all local service requests are pro- 15 
cessed locally at the. terminal where the local services are 
requested. The computing devices of the prior art, such as 
personal computers and workstations, can process local 
requests because of their computing power, memory and 
display capabilities. The mobile devices in the present 20 
invention, however, taking advantage of a cooperation 
between the interface engine and the control engine over the 
wireless network, services the requests with the limited 
computing resources of the mobile devices and without 
significantly compromising overall performance. 25 

Thus, unlike the closed and proprietary prior art mobile 
devices (e.g., mobile phones and two-way pagers), the 
present invention allows thinly designed mobile devices to 
become open application platforms. Such an open applica- 
tion platform allows software developers to develop value- 30 
added applications and services to these thinly designed 
mobile devices. Consequently, many more new uses can be 
developed for two-way communication mobile devices and 
two-way communication networks, including wireless 
networks, without physical modification or addition to the 35 
two-way communication mobile device. 

The present invention can be implemented in numerous 
ways. For example, according to one embodiment of this 
invention, a method of the present invention allows an 4Q 
interactive two-way communication mobile device with a 
display screen to interact with a network server. In this 
method, a control engine in a link server is initiated when the 
mobile device establishes a communication session with the 
fink server. (Such a link server couples the network server of 45 
a landnet, which uses a first communication protocol, to a 
wireless network which uses a second communication 
protocol.) The link server includes: (a) an account manager 
managing a user account associated with the mobile device; 
and (b) a message processor receiving a message from the 5Q 
network server over the landnet. Upon initiation, the control 
engine communicates with an interface engine of the mobile 
device corresponding to the user account, and converts the 
message, using the message processor, to a compact data file 
that can be efficiently transportable in the wireless network. 55 

According to another embodiment of this invention, in a 
method of the present invention, the link server sends over 
the wireless network a compact data file it generates, and the 
interface engine renders the compact data file to cause the 
display screen to display contents represented by the com- 60 
pact data file. 

According to still another embodiment of this invention, 
a system of the present invention includes: (a) a memory for 
storing code for a server module; (b) a data storage device 
for maintaining a user account for the mobile device; and (c) 65 
a processor coupled to the memory and the data storage 
device. The processor executes the code in the memory to 
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cause the server module to: (a) execute a control engine 
associated with an interface engine of a mobile device; (b) 
receive a network message from the network server over the 
landnet, using a first communication protocol; (c) buffer the 
network message in a cache memory; (d) generate a compact 
message from the network message; and (e) send the com- 
pact message to the mobile device over the wireless 
network, using a second communication protocol. 

According to still another embodiment of this invention, 
a system of the present invention includes: (a) a display 
screen; (b) an input means; (c) a memory for storing code for 
a client module; and (d) a processor coupled to the memory 
and controlling the display screen and the input means. The 
processor executes code in the memory to cause the client 
module to: (a) execute an interface engine when activating 
a predefined key; (b) maintain the interface engine to work 
with a control engine operating in the link server device in 
concert; (c) receive a compact message from the link server 
device over a wireless network, wherein the compact mes- 
sage is generated by a message processor in the link server 
device according to a network message received from the 
network server over a landnet; and (d) render the compact 
message to cause the display screen to display contents in 
the network message. 

Accordingly, one of the objects of this invention is to 
provide a generic solution to two-way communication 
mobile devices with limited computing resources to enable 
them to effectively interact with a landnet such as the 
Internet. 

Other objects, together with the foregoing are attained in 
the exercise of the invention in the following description and 
resulting in the embodiment illustrated in the accompanying 
drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention will be readily understood by the 
following detailed description in conjunction with the 
accompanying drawings, wherein like reference numerals 
designate like structural elements, and in which: 

FIG. 1 illustrates a schematic configuration in which the 
present invention may be practiced; 

FIG. 2 A depicts a block diagram of a typical GSM digital 
cellular phone that can be used in the data network of FIG. 
1 to practice the present invention; 

FIG. 2B illustrates an internal functional block diagram of 
an exemplary digital cellular phone that may corresponds to 
the GSM digital cellular phone of FIG. 2A; 

FIGS. 3A and 3B illustrate functional block diagrams of 
a link server device and a mobile device according to an 
embodiment of the present invention; 

FIG. 4 depicts an account structure used in the description 
of the present invention; 

FIGS. 5A and 5B illustrate respectively two exemplary 
screen displays on a display screen of a mobile device; 

FIG. 6 demonstrates an overview of a systematic con- 
figuration according to the present invention; 

FIGS. 7A to 7G illustrate a series of screen displays to 
illustrate the navigation of the Internet through a mobile 
device according to the present invention; 

FIG. 8A demonstrates an address table per device to send 
an address identifier to an actual IP address over a wireless 
network; 

FIG. 8B demonstrates an address table managed by an 
account manager to maintain groups of address identifiers in 
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a link server for all the mobile devices in communication 
with the link server; and 

FIGS. 9A and 9G illustrate a process flowchart of the 
present invention according to one embodiment. 

5 

DETAILED DESCRIPTION OF THE 
INVENTION 

Referring now to the drawings, in which like numerals 
refer to like parts throughout the several views. FIG. 1 
illustrates a schematic configuration in which the present 
invention may be practiced. As shown in FIG. 1, iandnet 100 
is a land -based network that may be the Internet, an Intranet 
or a data network of any private network. Coupled to Iandnet 
100 are a personal computer (PC) 110 and a network server 
104. Personal computer 110 may be a Pentium II-based 
desktop personal computer. Preferably, personal computer 
110 runs a HyperText Markup Language (HTML) browser, 
such as Netscape Navigator from Netscape Communications 
Corporation (http://www.netscape.com), via Iandnet 100 ^ 
using HyperText Transfer Protocol (HTTP) to access infor- 
mation stored in network server 104, which may be a 
workstation from SUN Microsystems Inc (http:// 
www.sun.com^. The information stored in network server 
104 may be hypermedia information including mobile data ^ 
designed for mobile devices. 

There are n mobile devices 106 serviced by airnet 102. 
Mobile devices 106 are interactive two-way communication 
devices (e.g., mobile computing devices, cellular phones, 
palm-sized computing devices with PDA (Personal Data 30 
Assistants) functionality and Internet-capable appliance 
remote controllers) which are capable of communicating 
wirelessly with antenna 108 via airnet 102. As shown, 
antenna 108 also represents a wireless carrier infrastructure 
that generally includes a base station and an operations and 35 
maintenance center. The base station controls radio or tele- 
communication links with mobile devices 106. The opera- 
tions and maintenance center comprises a mobile switching 
center performing the switching of calls between the mobile 
devices and other fixed or mobile network users. Further the 40 
operations and maintenance center manages mobile account 
services, such as authentication, and oversees the proper 
operation and setup of the wireless network. Each of the 
hardware components and processes in carrier infrastructure 
108 are known to those skilled in the art and thus are not 4 $ 
described here to avoid unnecessarily obscuring aspects of 
the present invention. 

Between Iandnet 100 and airnet 102 there is a link server 
device 114 functioning as a bridge between the two net- 
works 100 and 102. Link server device 114, which is also 50 
referred to as proxy server or wireless data server or network 
gateway server, may be a workstation or a personal com- 
puter. Link server 114, which is loaded with many processes 
including compiled and linked versions implementing the 
present invention, couples airnet 102 to Iandnet 100 and 55 
performs many functions as described in more detail below. 
One of the functions that link server 114 performs is to 
facilitate the communication of mobile devices 106 with any 
of the devices coupleci to Iandnet 100, including mapping or 
translating from one communication protocol in Iandnet 100 60 
to another in airnet 102 or vice versa. 

To facilitate the description of the present invention, FIG. 
2 A depicts a typical GSM digital cellular phone 200 that can 
be used as one of the mobile devices 106 in the arrangement 
of FIG. 1 to practice the present invention. Cellular phone 65 
200 includes a small screen 202 and an extended phone 
keypad 204. Screen 202 is typically a LCD display capable 
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of displaying perhaps four lines high by twelve or twenty 
characters with limited graphics capabilities. Extended 
phone keypad 204 includes, preferably, a regular phone 
keypad 206, a pair of generic keys 208 and 210 and 
positioning key 212. Generic keys 208 and 210 are used to 
activate soft keys displayed in screen 202 and positioning 
key 212 is to reposition an element indicator or a cursor to 
activate, for example, one of the hyperlinks displayed in 
screen 202. Generic keys 208 and 210 and positioning key 
212 are not necessary in practicing the present invention. 
These keys can be replaced by a set of designated [] keys 
in regular phone keypad 206 but provide preferred conve- 
nient means for a user to interact efficiently with the phone 
200. Further, having a regular phone keypad is not a 
requirement to practice the present invention. Some of the 
mobile devices have no physical keys at all, such as those 
palm-size computing devices that use "soft keys" or icons 
for receiving user input data. In the following, unless 
otherwise specifically described, keys or buttons are gener- 
ally referred to as either physical keys or soft keys. 

FIG. 2B illustrates a functional block diagram of digital 
cellular phone 200. Since each of the hardware components 
in digital cellular phone 200 is known to those skilled in the 
art, the hardware components are not described in detail. 
Besides keypad circuit 246 for keypad 204 and display drive 
248 for display screen 202, the main components in digital 
cellular phone 200 also include a random access memory 
(RAM), a read-only memory (ROM) and a physical layer 
processor or microcontroller 128. According to one 
embodiment, compiled and linked processes of the present 
invention are stored in ROM 250 as a client module 252 and 
a support module 254. Upon activation of a predetermined 
key sequence utilizing keypad 204, physical layer processor 
128 causes client module 252 to communicate with link 
server 114 of FIG. 1 via a radio transceiver 256. 

It is generally understood that a computing device 
equipped with an HTML browser using H i I P can access 
hypermedia information in a network server. However, 
HTTP requires considerable computing power and network 
bandwidth resources. For example, a request from a com- 
puting device to establish a communication session with a 
network server may require an exchange of a number of data 
packets. In addition to the resources required to implement 
HTTP, significant resources must be supported in the com- 
puting device to request, format, process and display infor- 
mation. This is not a significant disadvantage in many 
situations because the computing device, including personal 
computers and workstations coupled to a network operating 
HTTP, generally has sufficient computing power, memory 
and display capabilities. 

Nevertheless, cellular phone 200 or mobile devices 106 of 
FIG. 1 typically do not have the computing resources to 
implement HTTP to run an HTML browser. The computing 
power in cellular phone 200 or mobile devices 106 of FIG. 
1 is typically less than one percent of a laptop personal 
computer's computing power, the memory capacity is gen- 
erally less than 128 kilobytes and the graphics display 
capability is very limited. Cellular phone 200 or any of 
mobile devices 106 of FIG. 1 is not a replacement of a 
desktop computing device or the combination of a wireless 
communication module and a personal computer. Further, 
making a mobile device, such as cellular phone 200, capable 
of navigating hypermedia information in a network server is 
a significant departure from prior art systems. 

Referring now to FIGS. 3Aand 3B, there are respectively 
shown functional block diagrams of a link server device and 
a mobile device according to an embodiment of the present 
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invention. Link server device, or simply link server 300, that the form of, for example, 861234567-10900_ 

may represent link server 102 of FIG. 1, is typically a server pn.mobile.att.net by AT&T Wireless Service, and is a unique 

computer. Mobile device 350 may, for example, correspond identification to a mobile device. In other words, each of 

to one of mobile devices 106 of FIG. 1 or cellular phone 200 mobile devices 106 serviced by link server 114 in FIG. 1 has 

of FIG. 2. To avoid obscuring any aspect of the present 5 a unique device ID that corresponds to a respective user 

invention, well known methods, procedures, components account in link server 114. Additionally, account manager 

and circuitry in link server 300 and mobile device 350 are 312 is responsible for creating a user account for a mobile 

not described in detail. device that anonymously communicates with link server 

T . . . . . f 114. In this case, account manager 312 ensures proper 

Link server 300 includes a landnet communication pro- (limited) accessof the an0 nymous mobile device to services 

tocol (LCP) interface 302 that couples to landnet 304, and a 10 provided by server 114 

wireless communication protocol (WCP) interface 306 that FIG. 4 shows an exemplary structure 400 of the user 

couples to a wireless network 308 via a carrier's infrastruc- acC0 unts managed by account manager 312. It should be 

ture (not shown in the figure). LCP interface 302 implements noted that the ^ accounts nee d not be physically located 

a communication protocol operated in landnet 304. in unk server 300. In fact, the user accounts can be remotely 

Generally, landnet 304 operates HTTP, so that LCP interface 15 located in one of the computing devices coupled to the 

302 is typically an HTTP interface. Similarly, wireless landnet 104. Through account interface 314 that has proper 

network 308 may operate a wireless communication proto- and secure access to the user accounts, account manager 312 

col suitable for the characteristics of a wireless network. One can conduct the duties of account management, as discussed 

of the available wireless communication protocols is Hand- in further detail below. Device ID column 402 is filled with 

held Device Transport Protocol (HDTP) (formerly known as 20 the device IDs of mobile devices that correspond to sub- 

Secure Uplink Gateway Protocol (SUGP)), which runs on scriber IDs in subscriber ID column 404. Credential infor- 

User Datagram Protocol (UDP). In this embodiment, WCP mation column 406 lists credential information needed to 

interface 306 is implemented with a UDP or HDTP inter- access each associated account. User info 408 may include 

face, HDTP is developed by Openwave Systems Inc. the acc0UQt configuration information, for example, device 

(formerly Unwired Planet, Inc.) located at 140 Seaport 25 ID "6508 11 '1453" is a mobile phone that is pre -configured to 

Boulevard, Redwood City, Calif. 94063. The specifications wo ' k m a CDPD nQiW0 ^ a ^ probably, may be provided 

of HDTP, entitled "HDTP Specification" is enclosed and Wlth u an °P t ? on to swi . tc , h t0 * GSM network if necessary. 

» j u ■ u e • * Further entries in user info column 408 may include pointers 

incorporated herein by reference in its entirety. , AAn . , , „ / i_ 

r 3 J or linkages 410 to other account-related information, such as 

To facilitate the description of the present invention, the system parameters, encryption schemes, call plan and cus- 

wireless communication protocol in use is HDTP. The tomer service information that can be accessed by the 

present invention is, however, not limited by this exemplary mobile device. 

communication protocol. Returning now to FIGS. 3A and 3B, a database of user 

HDTP is a session-level protocol that resembles HTTP accounts permits account manager 312 to authenticate and to 

but runs on UDP and without incurring the overhead of verify the subscribed mobile devices and to control access to 

HTTP/TCP and is highly optimized for use in thin devices, provided services by all mobile devices (subscribed or 

such as the mobile devices, that have significantly less anonymous devices) via wireless data network 308. More 

computing power and memory than those of a desktop importantly in the present invention, account manager 312 is 

personal computer. Further, UDP does not require a connec- responsible for managing the operations of control engines 

tion to be established between a client device and a server An 320 ' whl <* ar * respectively and independently designated to 

before information can be exchanged, which eliminates the 4 ° one mo ^ device. The detailed operations of control 

need of exchanging a large number of packets during a Gn &™™ ™ P ? V }* X ™ A „ A . 

session creation. Exchanging a very small number of pack- . ™ e f° llowin g description is focused on mobile device 

ets during a transaction is one of the desired features for a 350 a ° d lts asS0C f ed a ™; However the present 

i .* i , . i . • . j , A description is equally applicable to any mobile device in 

mobile device with limited computing power and memory to 4S comm Wcation with link server 300. 

effectively interact with a landline device. , , Jlt . j i * i j 

J In addition, server module 310 includes message proces- 

Link server 300 further comprises a server module 310 so r 3^ w hich includes a message digester 316 and a 

coupled between LCP interface 302 and WCP interface 306. converter 318. Message processor 315 processes messages 

Server module 310, which is typically loaded in a memory, communicated between a network server and link server 300 

performs traditional server processing as well as protocol 50 and generates for each message a corresponding compact 

conversion processing from one communication protocol to message to be communicated between link server 300 and 

another communication protocol. In particular, the protocol mobile device 350. In particular, message digester 316 

conversion processing includes protocol conversion receives the messages from the network server and performs 

between HDTP/UDP and HTTP/TCP according to one a sequence of message processing that include interpretation 

embodiment. S5 anc j management of the messages. Converter 318 converts 

In server module 310, account manager 312 manages the messages, according to the interpretation, to a data 

through account interface 314 a number of user accounts for format that is compact enough to be efficiently transportable 

all the mobile devices serviced by link server 300. Each of over wireless network 308. The messages received from the 

the mobile devices, such as 350, is assigned a device network server are typically markup language files or data, 

identification (ID). Device ID can be a phone number of the 60 requests, notifications and other commands that could cause 

device or an IP address or a combination of an IP address and mobile device 350 to respond as desired in the received 

a port number, for example; 204.163.165.132:01905 where messages. The markup language may include, for example, 

204.163.165.132 is the IP address and 01905 is the port Handheld Device Markup Language (HDML), HyperText 

number. The device lD is further associated with a sub- Markup Language (HTML), compact HTML, Wireless 

scriber ID created and administrated by a carrier in link 65 Markup Language (WML), Standard Generalized Markup 

server 300 as part of the procedures to activate a subscriber Language (SGML) and Extensible Markup Language 

account for mobile device 350. The subscriber ID may take (XML). 
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For example, LCP interface 302 receives an HDML file causes a screen to display the contents of the corresponding 

from a financial network server that directs mobile device markup language file. 

350 to display a pre -designed screen, in response to mobile In other words, the actual data being exchanged between 

device 350's request to the financial network server. The link server 300 and mobile device 350 is in SDD format, 

exemplary HDML file is listed as follows: 5 which is typically binary and can be communicated more 

<HDML VERSION-2 0> compactly and efficiently in wireless network 308. Further 

<DISPLAY NAME> SDD files can be directly rendered by an interface engine in 

< Ar-nrw tvdJ a ^i:dt tacv nr\ hcct mobile device 350 without further processing. Nevertheless, 

<ACTION TYPE-ACCEPT TASK-GO DEST- (he aboye procedures are ^itri for illustrative purpose 

#card2> on jy anc j me p^g^ invention is not limited to the Imp data 

Dow has hit 20,000 today! ™ format According t0 another embodiment( the messa g e 

Nasdaq bas popped 20%. processor does not have a pair of separate message digester 

Detailed Financial Headlines an d converter, a markup language file in HDML, compact 

</DISPLAY> HTML or XML is received at the message processor and 

</HDML> converted into a corresponding binary file that is much 

The screen display corresponding to this HDML file is 15 smaller in size and may be in Imp, cHDML, cHTML, or 

shown in FIG. 5A. If a user selects the "OK" soft key, a list cXML, wherein "c" means stripped, compressed, compiled 

of the detailed financial news packaged in one or more or converted version of the corresponding markup files. 

HDML files would be fetched (pulled) from the financial To interact with mobile device 350, server module 310 

network server and displayed, as shown in FIG. 5B. As used £urther . lncludes .™& ne . 32 » Coalro } en g me 320 

herein, a display screen or screen is the physical display 20 m conjunction with an interface engine in mobile 

apparatus in a device, such as a 4 by 20 character LCD device 350 and w " h message processor 315 to 

screen in a mobile device or 2.5 inch by 3.5 inch touch LCD mte u r P' et actl °°f fr ° m "P 0 ^ device 3S ? » n f he P resent 

screen in a palm-sized computer. A screen display is the embodiment. More detailed description of the interactions 

image presented on the display screen. As shown in FIG. SB, betwe ^ D the in *? ace eo ^ e m ™ b ,'' e device 35 » and 

display screen 500 shows a list of choices with element 25 contxol engine 320 in server module 310 is given below, 

indicator 510 pointing to the first choice. Pointer 512 indi- c MobUe device 350 includes a corresponding WCP inter- 

cates that screen display 508 has more items to be displayed face 35 ? that f^P'f 10 a,rnet 308 via . a f ansceiver (™< 

but limited by the size of display screen 500. show ° In *L fi ? uni > 10 K *™. inc °T ng and oul .g° ln g, data 

As described above, mobile device 350 typically does not sl S nals - WCP 3 j 2 ,s ■ implemented with a UDP 

have the necessary computing power and memory to operate 30 ""<; rface ' 85 wh ? WlreleSS netWOrk 

a browser in response to the HDML files. Therefore, an 308 °P c 1 rates HDTP When another weless communication 

HDML file received is first analyzed by message digester ? mo ?° l » °P erated ™ '"? rd ? S "^P* 3 ° 8 ' !? th . W ? P 

316 and then converted through converter 318 into a set of mterface a WCP interface 306 are readily imple- 

screen commands that cause a mobile device, upon receiv- mented accordingly so that link server 300 and mobile 

ing the screen commands, to display the contents in the 35 dey.ce 350 can communicate with each other. 

HDML file according to the screen commands. Typically, „,^ vice f ent ^2?) ! tora 8 e 35 * su PP hes a device ID to 

the screen commands are expressed in a form of screen ^CP mterface 352. The device ID identifies a mobile device 

description data (SDD) that is rendered in an interface 350 ^d directly corresponds to the device ID in the user 

engine in mobile device 350. The following is an example of acc ° u f in ,lnk xnel ' 300 ,L" add,llon V moblle device 350 

an SDD stream* 40 inc ' uc ^ es a c l ient module 356 that performs many of the 

* M «^ L M ^ — « processing tasks performed by the mobile device 350. Such 

0632 302^ processing tasks include establishing a communication ses- 

sion with line server 300 via carrier network 308, requesting 

3030 3057 0574 6f64 6179 eOOl 2152 0844 6574 6169 anci receiving data from carrier network 308, displaying 

6c65 64e0 45 information on a display screen 360, and receiving user 

0946 696e 616e 6369 616c e009 4865 6164 6c69 6e65 input data. Specifically, client module 356 is coupled to 

73ff WCP interface 352 to establish a communication session and 

which is considerably smaller than the corresponding to request and receive data. Additionally, Client module 356 

HDML file. The "ASCII-like" representation of the above operates, among other things, an interface engine 364 that 

illustrated SDD file is: 50 typically receives the screen description data from link 

type-screen seq-num-54 server 300 and causes display drive 260 to display on the 

<WRAP>"Dow" ofiket-4 "has" ofifeet=8 "hit" display screen what is intended in the HDML file originally 

<WRAP>"20,0(Xr offset-7 "today" rec A eived from th f network server. 

wrap "i" fF ? "n H" mentioned above, in prior art systems, terminal 

< > « • ° 6 ~» e 31 C 55 devices typically run a local browser such as the one from 

<WRAP>"Financial" Netscape or Microsoft to interact with the Internet. The 

<WRAP>"Headlines" present invention, however, uses an interface engine in a 

<end> terminal device and a control engine in a proxy server. In 

Transmission of a smaller data file is important in wireless other words, the present invention uses an interface engine 

data networks that are characterized with low bandwidth and 60 demanding little computing resources in a wireless mobile 

expensive airtime. According to one embodiment, the SDD device and a control engine utilizing sufficient computing 

file is a group of Imp data, the detailed specification of the resources provided in a server device to allow the mobile 

Imp data is provided in the Appendix entitled "Imp Speci- device to effectively interact with a network server. Further, 

fication protocols between Femto Engine and Terminal", working with the control engine in the link server, the 

which is hereby incorporated by reference for all purposes in 65 interface engine in the mobile device does not need consid- 

its entirety. There are a set of rules or grammars in the Imp erable computing power or memory to cache, parse, process 

data that an interface engine, upon rendering the Imp data, and display a markup language file. 
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To facilitate further description of the present invention, information to be displayed to the user. The displayed 

FIG. 6 demonstrates an overview of a systematic configu- content can include any one of, or any combination of text, 

ration according to the present invention and should be image, and soft keys. Achoice card displays a list of choices 

understood in conjunction with FIG. 3. FIG. 6 shows that a to the user. The choices are presented in a format specified 

mobile device 602 communicates with a network server 604 5 on the choice card and are generally numbered sequentially, 

via link server device 606. Network server 604, or some- As explained above, the user selects a choice by depressing 

times called service server, may be any server on the Internet a corresponding key. An entry card is used to obtain input 

that provides accessible hypermedia information. Mobile data from the user. An entry card displays one or more entry 

device 602 and link server 606 may correspond respectively lines. The entry line, in this embodiment, can be used to 

to mobile device 350 and link server 300 in FIG. 3. Service 10 receive either numeric or text data. A no-display card is a 

server 604 having an IP address, for example, hidden card which is not displayed. The no-display card is 

www.abcnews.com, provides hypermedia information to normally used to execute an intermediate action and gener- 

network 608 so that computing devices coupled to network ally not known to a user. Regardless of its type, a card can 

608 can access the information in service server 604. contain text, soft keys and images. 

According to one embodiment, the information in net- 15 In one aspect and from the perspective of a browser 

work server 604 is a World Wide Web page that may be operating HDML, choice and entry cards prevent a user 

authored in HDML and fetched over network 608 operating from moving to the next card until the requested information 

HTTP. From the perspective of mobile device 602 that is received from the user. When the user reaches the last card 

ultimately receives the information, link server 606 receives in a deck and hits a corresponding key, a request for a new 

the HDML files that are then processed by message proces- 20 deck is initiated. The deck requested is determined by either 

sor 610 and converted to screen description data according the deck that the user has completed, or by the choices made 

to the device characteristics of mobile device 602. The by the user. When the deck is completed, the choices and/or 

device characteristics may include the type and size of data entered by the user are typically transmitted along with 

display screen and other information passed over link server the request to a network server for a new deck. When a deck 

606 when a communication session is established between 25 containing multiple cards is received and stored in a cache 

mobile device 602 and link server 606. Generally, a request memory, the browser fetches the first card in the deck, 

to establish the communication session can be initiated by displays the information in the card, and allows the user to 

either mobile device 602 or link server 606. During the respond thereto. Depending on the card type, the user 

process of exchanging authentication information, the data responds by entering text or choosing an option, and then 

carrying the device characteristics of mobile device 602 is 30 pressing a predetermined key to transact the response, 

received and maintained in link server 606 such that the FIGS. 7A through 7G should be understood in conjunc- 

screen description data is generated in accordance with the tion with FIG. 6 and with reference to FIG. 3. Upon 

device characteristics of mobile device 602. The detailed establishing a communication session between mobile 

description of initiating the request and the processing of device 602 and server device 604, an initial HDML deck 

exchanging information so as to subsequently establish a 35 transmitted to link server 606 includes an introductory 

secure and authenticated communication session . is display card and a choice card. FIG. 7A is an example of 

described in commonly assigned U.S. patent application Ser. introductory screen display 702 that is ultimately drawn on 

No. 08/966,988 entitled "Method and System for Secure a display screen 700 of mobile device 602 by interface 

Lightweight Transactions in Wireless Data Networks" by engine 616. FIG. 7 A and the following figures are not 

Hanqing Liao et al, which is hereby incorporated by refer- 40 interpreted directly from the HDML decks received, rather 

ence in its entirety, are interpreted from corresponding screen description data 

With the established communication session, the screen translated in link server 606 according to the HDML decks 

description data are .then forwarded to mobile device 602 received therein. As described above, if working directly 

over wireless network 614 operating a wireless communi- with the HDML files, the terminal (i.e., the mobile device) 

cation protocol. Upon receiving and rendering the screen 45 would require both considerable memory to cache the 

description data, interface engine 616 causes display screen HDML files, history and activity states and sufficient com- 

618 to display the information embedded in the screen puting power to run a browser to work with the cached 

description data. HDML files. One aspect which differentiates the present 

FIGS. 7 A through 7G show the processes of navigation invention fundamentally from prior art systems is that the 

requests by mobile device 602 of FIG. 6 and fetching 50 control engine in the link server is responsible for tasks that 

requested information from service server 604 and forward- require computing resources while the interface engine in 

ing the information subsequently from fink server 606 to the terminal is only responsible for rendering the screen 

mobile device 602. description data to cause the display screen to display 

Prior to describing FIGS. 7A through 7G, some of the contents and receive inputs from a user. More specifically, 

features in HDML are recited. Similar to HTML, HDML is 55 the typical functions that the control engine in the link server 

a tag-based document markup language which includes a set perform include: 

of commands or statements specified in a card that defines i. processing requests from the mobile device; 
how information is displayed on a small screen. Normally a 2 . generating a URL request to a network server; 
number of cards are grouped into a deck that is the smallest 3 interpreting markuo laneuaee files- 
unit of HDML information that can be exchanged between 60 ' *P S P P\ § ' 
network server 604 and link server 606 over landnet 608. 4 ' g eneratul g screeQ description data; 
The HDML specification entitled "HDML 2.0 Language 5 - management of data cache; 
Reference" is enclosed and incorporated herein by reference 6. management of history; 

in its entirety. 7. management of variable states in a markup language 

According to one embodiment of the HDML, there are 65 file; 

four typical types of cards: a display card, a choice card, an 8. maintaining push data, including alerts, electronic 

entry card, and a nb-display card. A display card gives mails. 



06/22/2004, EAST version: 1.4.1 



US 6,473 : 

13 

According to one embodiment, display screen 700 dis- 
plays a graphical image. In another embodiment, display 
screen 700 displays only text. Screen display 702, and other 
screen displays described more completely below, include a 
horizontal arrow 704, i.e., a multi-screen indicator translated 5 
from a multi-card deck indicator, to communicate to the user 
that screen display 702 includes another screen display. To 
view the HDML file, a multi-card deck indicator indicates 
that the current deck includes another card. The inclusion of 
screen indicators, such as horizontal arrow 704, to commu- 10 
nicate with the user is optional. The functionality of this 
invention is independent of such screen indicators. 

Referenced by 706 is a soft key generally associated with 
one of the generic buttons in the keypad of the mobile device 
602. A soft key can be used to map a generic button into a 15 
specified button or activated by a touch pen or a finger. In 
this instance, pressing the generic button or touching the key 
directly is equivalent to pressing an "OK" button when the 
soft key OK is displayed. In many palm-sized computing 
devices, the number of the keys is generally kept to a 20 
minimum so as to provide a larger display screen. The larger 
display screen can accommodate more soft keys, which can 
be directly activated using a touch pen. Soft keys thus 
provide an efficient means to interact with display screen 

700. 25 

When the user depresses a predetermined key (i.e. one of 
the generic buttons in this case), thus selecting a soft key, a 
client module in the mobile device 602 interprets the action 
and sends a request to link server 606. Upon receiving the 
request, control engine 609 in link server 606 interprets the 30 
request which is, in this instance, a request to display the 
next screen display. Control engine 609 calls converter 612 
to retrieve the next card from the received HDML deck, 
preferably, cached in a memory in the link server and 
converts the card in HDML to a SDD file that is subse- 35 
quently delivered to mobile device 602. Upon receiving the 
SDD file, interface engine 616 draws a new screen display 
as shown in FIG. 71}. 

Screen display 708 in FIG. 7B shows a list of choices (the 
original HDML card is a choice card). Besides a list of 40 
choices that can be accessed by the user in FIG. 7B, there is 
a downward arrow which indicates that the screen display 
includes additional items that are not shown in display 
screen 700. The screen display can be larger than the number 
of lines available in the display screen 700 and so the user 45 
must scroll the screen display to view the complete screen. 
Thus, to view the additional items, the user presses the 
downward arrow key corresponding to the downward arrow 
indicator 712 on the display screen 700. In this embodiment, 
when the downward* arrow key is pressed, each line of the 50 
display is rolled up one line. The resulting display has an 
icon with an upward arrow (not shown) if the menu requires 
only two screen displays. If the menu requires more than two 
screen displays, the second screen display of the menu 
would have two icons, one with the upward arrow and 55 
another with the downward arrow. To scroll between the 
various lines in the second menu, the user uses the down- 
ward arrow key, and the upward arrow key. If the user 
displays the last line of a card, e.g., the last line in the second 
menu, and presses the downward arrow key nothing would 60 
happen because the downward arrow icon, another soft key, 
will not be present. 'In this screen display, the user must 
make a choice before a next display screen is available. 

In this embodiment, each of the menu items is available 
on service server 604 or distributed on several server com- 65 
puters coupled to network 608. As explained more com- 
pletely below, each of the menu items in the original HTML 
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file is associated with a numeral that corresponds to a 
resource locator in the card containing the menu items. The 
resource locator includes an address of a particular object 
associated with one of the menu items. In general, a resource 
locator includes a universal resource identifier (URI) or 
universal resource locator (URL) and may include appended 
data. The address can be referenced to another card in the 
deck cached in link server 606 or to a remote object on 
service server 604. 

As shown in FIG. 7B, the first item in the menu 708 is 
initially indicated by an arrow 710 as a pre-chosen item. If 
the user decides to proceed with the pre-chosen item, the soft 
key "OK" may be pressed. Alternatively, a numbered key 
"1", i.e. one of the 10 numbered keys, can be pressed to 
cause the client module in mobile device 602 to send a new 
request to link server 606 for a next screen display. This new 
request, however, is not a simple request as the one from 
FIG. 7 A. This request may include a resource locator to 
another card in the deck cached in link server 606 or a 
remote object in service server 604, depending on whether 
the original received HDML includes the information 
requested by the new request from mobile device 602. 

This new request corresponds to a hyperlink in the card 
that has been converted to the SDD file currently being 
displayed in FIG. 7B. The hyperlink may include a URL as 
follows: 

www.xyzinfo.co m/Sof too rp/sa les 

where www.xyzinfo.com can be the URL of service server 
604 and/sales may be a hyperlink in an object identified 
by/Softcorp in service server 604. More specifically, the card 
in the original HDML file may be expressed as follows: 
<HDML version-"2.0"> 
<CHOICE> 

<CE TASKoGO DEST-www.abc.com/sales.hdmi> 

ABC Corp. Sales 
<CE TASK-GO DEST= www.xyzinfo.com> 

XYZ Information 
<CE TASK«GO DEST»www.financialinfo.com> 

Financial Info 
<CE TASK=GO DEST=www.personalweb.com> 

Personal Web Site 
</CHOICE> 
</HDML> 

In the present example, each of the items in the menu 
displayed in FIG. 7B corresponds to a URL in the following, 
identifying a network server in the Internet: 

www.abc.com/sales.hdml 
www.xyzin fo.co m 
www.flnancialLnfo.com 
www.personalweb.com 

When one item is subsequently chosen, the control engine 
will generate a URL request to the identified network server 
to retrieve the desired information. 

Although converter 612 in fink server 606 converts the 
above code to a SDD file, a much more compact format for 
transmitting over wireless network 614. A long address, like 
http:/Avww.xyzinfo.com/LocalNews/Towns, typically can- 
not be compressed further. It is neither efficient nor wise to 
use the wireless network to communicate a number of long 
addresses in a file and return a URL request containing one 
or more of the addresses. Hence the present invention uses 
one or more address identifiers that are communicated over 
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the wireless network. Each of the address identifiers iden- 
tifies the full address. An address table is maintained in link 
server 606 that maps the address identifiers to the actual 
(full) addresses. The address identifying or address mapping 
methods described here are significantly different from prior 5 
art systems which send addresses to all hyperlinks in a 
markup language document along with the document to a 
terminal device. 

FIGS. 8A and 8B show, respectively, two implementa- 
tions of address mapping and should be understood in 10 
conjunction with FIG. 3 and FIG. 6. Address mapping table 
800 is identified by a user ID 802. Address mapping table 
800 includes address identifier column 804 and addresses 
into address buffer 806. Address mapping table 800 in FIG. 
8 A is typically established when a communication session is 
between a mobile device and a link server is created. Each 
mobile device is allocated one address mapping table, and 
can be managed by the account manager in the link server. 
In other words, user ID 802 (e.g., a device ID or a subscriber 
ID) associates uniquely a mobile device to address mapping 20 
table 800. During the communication session, only the 
entries in address ideptifier column 804 are actually sent. For 
example, rather than sending over the entire resource locator 
http:Avww.xyzinfo.com/LocalNews/Towns, address identi- 
fier "1234" is embedded in a SDD file that is delivered to the 25 
mobile device. Generally mapping table 800 in FIG. 8A 
vanishes when the session expires or terminated. 

According to another embodiment, the account manager 
manages an address mapping table 800 shown in FIG. 8B, 
in which user ID column 802 includes identifications (e.g. 30 
device ID or subscriber ID) of all active mobile devices 
communicating with the link server. Address identifiers 804 
includes all address identifiers corresponding to the actual 
addresses in address* buffer 806. Thus, whenever a mobile 
device refers an address identifier to a resource locator, the 35 
actual address is retrieved from address buffer 806 using the 
address identifier and used in a URL request generated by 
the control engine to the identified network server. 

According to another embodiment in which the SDD is a 
group of Imp data, the actual addresses are mapped to their 40 
relative positions in a final screen display. For example, the 
above four URLs are hyperlinks, according to the original 
HDML file, to be displayed one in each of successive lines. 
Thus their relative positions, linel, line2, line3 and line4, 
each corresponds to one of the URLs. The relationships 45 
between the relative 'positions and the actual URLs may be 
maintained in the address table discussed above or directly 
by the control engine. If a user eventually chooses one of the 
hyperlinks, a (client) request from the mobile device will 
include the chosen position. The request may be expressed 50 
as follows: 

client rcquest={SeqID, link, topline}; 

where "SeqID" ensures that the client request is synchro- 
nized with the Imp data fetched to the mobile device, from 55 
which the. client request is produced, "link" is one of the 
parameters that indicates which link (URL) is chosen and 
"topline" is the position in the screen display from the Imp 
data. For example: client request-{64, 2, 0}; Upon receiving 
the client request, the control engine processes the request 60 
and produces an updated request including the actual URL 
corresponding to the chosen position, for example {"http:// 
www.xyzinfo.com"}, which causes a connection to the 
service server identified by the URL. 

Returning to FIG. 7B, the user may scroll the choice 65 
arrow 710 downward if the pre-chosen item is not a wanted 
one. It should be noted that scrolling to a selected item is a 
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feature that is specific to this example, and in general is not 
required to implement the invention. Other methods can be 
used to indicate the user's choice on display screen 700 such 
as a horizontal highlighting strip overshadowing the choice, 
if such an indication is desired. As described above, the user 
may simply key in one or more numerals to select an item 
that is of interest. 

As described above, screen display 716 also includes the 
representations of two soft keys, an OK key 706, and a Back 
key 714. In this example, these soft keys are defined only for 
the card used to generate screen display 716. The "OK" key 
allows the user to proceed with the chosen item and the 
"Back" soft key allows the user to go back the previous 
screen display if so desired. In the present invention, the 
"Back" soft key may generate a request that is sent over to 
the link server from which the previous screen display is 
fetched again. Other keys can be implemented. For example 
a "Home" key, resulting in a request that returns the user to 
screen display 708 of FIG. 7B. The "Home" key may be 
associated with a resource locator identifying the card 
representing screen display 708. Specifically, the link server 
manages a limited history stack of recent requests made by 
the mobile device in a memory. When a request is made, the 
control engine looks up the history stack to see if the request 
is an "old" one. For example, when the "Home" key is 
pressed, the request can be found in the history stack and the 
contents, either in the form of an HDML card or an SDD file, 
can be retrieved from memory and forwarded to the mobile 
device for display. 

As shown in FIG. 4C, the user moves arrow 710 down- 
ward to the second item. Display screen 716 shows four 
menu items numbered consecutively. As described above, 
the downward arrow indicates that there are more items in 
the next screen. Each of the items has an address identifier. 
For example, for the first four items, the respective address 
identifiers may be: 

12ab 
231a 
1629 

each address identifier correspond to an address stored in the 
address buffer of link server 606: 

www.abc.com 

www.xyzinfo.com 

www.financialinfo.com 

www.personalwcb.com 

When the second item (i.e., 231a) is chosen, www.xyzinfo- 
. com is intended. After a predetermined button is pressed 
(e.g., the soft key OK or the numbered button "2") is 
pressed, a request including the address identifier for the 
selection is transmitted to link server device 606 by the 
client module in mobile device 602 over network 614. 
Alternatively with regard to the specific Imp data 
implementation, the request includes the selection in terms 
of the relative position in a display screen as described 
above. In response to the selection, control engine 609 
processes this request and formulates a new or updated 
request containing the actual URL identified in the client 
request, which causes a connection to service server 604. 
Through the server module, the link sever receives another 
HDML deck file from service server 604. Upon receiving the 
new HDML deck, message processor 610 processes the deck 
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for the desired card and sends a corresponding SDD file 
derived from the desired card to mobile device 602. 

In FIG. 7D, there is shown a new screen display 718. 
Typically, it is from one of the cards in a new deck received 
in the link server as a result of the request from screen 
display 716. The deck is cached in the link server and the 
first choice card is converted to a SDD file that is rendered 
by the interface engine in the mobile device for display. If 
the user proceeds with any of the items, for example, "Local 
News", a request is made from the interface engine in the 
mobile device and received by the corresponding control 
engine in the link server. The control engine causes the 
message processor to retrieve a card identified by the request 
from the cache and convert the card to a SDD file and 
forwards the file to the mobile device for display. 

FIG. 7E shows a display screen 718 resulting from the 
"Local News" request. Display screen 718 asks the user for 
specific date information so that the news corresponding to 
the specified date can be provided. The original HDMLcard 
that corresponds to display screen 718 is an entry card that 
requires an input from the user. Hence the corresponding 
SDD file converted from the HDML entry card requires the 
input at cursor 720. FIG. 7F shows that the input 722, i.e. 
date information, is typed in. Upon pressing soft key "OK" 
706, the interface engine sends a request including the input 
data to the control engine that performs variable substitu- 
tions. Variable substitutions, permitting sharing of data 
between cached cards, substitute the variable in the original 
HDML card with the actual information. As a result, an 
updated HDML card is locally and dynamically generated 
and then converted to a new SDD file that is returned to the 
interface engine for display. FIG. 7G shows a screen display 
724 with the substituted data information. In this example, 
the updated HDML card is another entry card, hence screen 
display 724 asks for further information in order to deliver 
accurate information to the user. If the user supplies the 
"town" information being requested and presses the "OK" 
soft key, a request is made and sent to the link server in 
which the supplied information is used to substitute a 
corresponding variable and an updated request with the date 
and town information is generated. Typically, the updated 
request is sent to the network server supplying the 
information, but the updated request may be filled locally in 
the link server if the original HDML deck is large enough to 
include the desired information. Further detailed description 
of the management and processing of the variables in a 
markup language file is provided in commonly assigned 
U.S. patent application Ser. No. 09/071,235 entitled 
"Method for Inline Variables Management in a Hypermedia 
Display Language" by Peter F. King et al, which is hereby 
incorporated by reference in its entirety. 

FIGS. 9 A to 9G tpgether constitute a process flow dia- 
gram showing the process performed by a link server device 
and a mobile device according to one embodiment of the 
present invention and should be understood in conjunction 
with FIGS. 3A to 3B and FIG. 6. At 904, link server device 
exchanges information with the mobile device to establish a 
communication session. The request to establish a commu- 
nication session is initiated from the link server by sending 
a message to the targeted mobile device. The message 
includes a device identification of the mobile device. Upon 
receiving the message, the mobile device starts exchanging 
information with the link server. The exchanged information 
may establish the encryption keys and the encryption 
scheme to be used for the session. In addition, the mobile 
device delivers to the link sever a set of device character- 
istics information regarding the type and size of the display 
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screen of the mobile device. At 906, the account manager in 
the link server associates the device information with the 
session just established. Typically the device information is 
cached in a memory along with other information about the 

5 mobile device. If the mobile device is an authorized device, 
there is a corresponding account that was established when 
the mobile device is activated. If the mobile device contacts 
the link server the first time, an account is established by the 
account manager. Therefore, the device characteristics infor- 

30 mation is always associated with the account of the mobile 
device. 

At 908, the account manager assigns a control engine to 
work in conjunction with the interface engine in the mobile 
device. At 910, the account manager detects, through the 
server module, any message arrived. At 912, the source of 
15 the message is identified (i.e., whether the message is 
received from a network server or from the mobile device). 

At 914, when the received message is from the network 
server, the control engine along with other modules in the 
link server determines the message type. In this 
20 embodiment, there are primarily two message types that are 
processed distinctively from the prior art systems. 
Specifically, these message types are notifications and 
markup language (ML) files. The notification or alert mes- 
sage indicates the arrival of an electronic mail or fulfillment 
25 of certain requests (e.g., sale of a stock at a limit price). The 
notification or alert message includes a device identification 
identifying the mobile device, an alert type (instructing the 
mobile device to beep, vibrate or display a visual sign), an 
alert title (a text string describing the subject matter of the 
30 alert), a life-time specifying a time period during which the 
alert should be delivered) and a URL that a user can request 
when the user desires to respond to the alert. Alternatively, 
an alert can be expressed as follows: 
Notification tf/(frf ={023, "new mail", 4, www.wireless.com/ 
35 mail retrieval/87473} where "023" is a special code that 
can causes the mobile device to beep, the title "new mail" 
is then displayed on the screen of the mobile device, the 
value "4" specifies that the notification message be deliv- 
ered within four hours or discarded, and the last entry in 
40 the notification is the URL to retrieve the new mail 
identified by "87473" from a mail server identified by 
www.wireless.com. 

As indicated above, a notification or alert message is not 
always immediately deliverable; sometimes the mobile 

45 device is out of the service area or the mobile device is 
turned off. Consequently, the account manager of the link 
server maintains a notification list or an alert list for each 
mobile device. Upon receiving a new alert message, at 916, 
the account manager determines from an alert list if the 

50 newly arrived alert message correspond to a URL already on 
the alert list. If there is an identical URL in the alert list, at 
920, the corresponding entry in the alert list is updated with 
the newly arrived alert message. If no identical URL is 
found, at 922 the newly arrived alert message is inserted. 

55 The newly arrived alert messages are sequenced in the alert 
list for delivery to the target mobile device. 

At 924, the alert message is modified by substituting the 
actual URL by an address identifier retrieved from an 
address table. At 926, the modified alert message is sent to 

60 the mobile device over the wireless network. It should be 
pointed out that the above alert list update is not necessary 
if the newly arrived alert message is immediately delivered. 
Further it should be pointed out that the alert list may not be 
necessarily maintained in the link server device and, as will 

65 be explained below, may be maintained in the mobile device. 
Returning to 914, wherein the received message from the 
network is a markup language (ML) files. At 938, the 
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message processor in the link server processes the ML files. 
The processes at 938 may include caching the ML files in 
proper memory, parsing the ML files to generate internal 
data structure needed to generate SDD files. In particular, at 
940 and 942 all the URLs in the received ML files are 5 
substituted by corresponding address identifiers, with the 
actual URLs stored in the address table maintained in the 
link server or the relative positions of URLs are determined 
with regard to the Imp data implementation. At 944, the 
message processor converts the processed ML files to SDD 10 
files corresponding to the mobile device's characteristics 
information, to allow proper display of the SDD files in the 
mobile device. To ensure that the control engine in the link 
server is in synchrony with the interface engine in the mobile 
device, at 946, the SDD files are respectively sequenced, is 
preferably numbered consecutively and, at 948, delivered to 
the mobile device over the wireless network. 

Returning to 912, wherein the message is from a mobile 
device. Typically, such a message includes one or more 
(client) URL requests. At 960, the control engine processes 20 
the message after the account manager verifies that such 
requests are permissible at 958. Depending on the services 
subscribed, each mobile device serviced by the link server 
may have the different privileges from other mobile devices 
to the services offered by the link server. If a request is 25 
granted at 958, the link server processes the request. 
Collectively, a (client) request may be expressed as follows: 

client request= {Seq ID, Event, Choice, Link, AJterlD, Topline, 

Entry, URL} 3Q 

where "SeqID" ensures that the client request is synchro- 
nized with a SDD fetched to the mobile device, from which 
the client request is produced. "Event" indicates what kind 
of request this client request is, for example, Softkey mean- 
ing a soft key activation, AlertSelect meaning that an alert 35 
has been responded to fetch a message in reference to the 
alert, and "Accept", "GotoURL" and "DeleteSelect", to 
name a few. "Choice" indicates which choice in a screen 
display has been chosen, "link" is one of the parameters that 
indicates which link (URL) is chosen. "AlterlD" comprises 40 
one or more those address identifiers. "Topline" is the 
position in the screen display from the SDD and "Entry" 
typically holds inputs entered by a user and "URL", as the 
name suggests, holds an address enter by the user. 

At 960, the request is processed. Generally, the request is 45 
to request information. In some instances, at 962, variables 
in the requests are substituted to provide an updated request, 
as explained below. * 

According to one aspect of the invention, variables are 
used to hold user input data. Such user input data can be 50 
collected, for example, in response to a query provided to the 
user in a display screen. When the user input data (e.g., a 
number) is entered by the user, the user data received is 
provided on the next display screen to provide feed back to 
the user. Specifically, the link server receives an ML file in 55 
which are defined a number of variables. The variables in the 
ML file constitute information to be requested at a terminal 
device. When the ML is converted to a corresponding SDD 
file to be displayed op the mobile device, in response to the 
display screen, the user enters the required input data and a 60 
request is dispatched containing the input data to the link 
server, after a predefined key is pressed. In prior art systems, 
a terminal device running a browser performs the substitu- 
tions locally. In the present invention, the mobile device 
operates only an interface engine without the capability of 65 
performing the substitution. The substitutions are performed 
by the control engine in the link server when the request 
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from the mobile device is received at 964. The link server 
responds to the request by sending the mobile device a new 
SDD file that has the user data substituted for the variables 
at 966. 

According to another aspect of the present invention, 
some values received from the mobile device for variables 
in the ML files are provided as address identifiers that must 
be substituted with the actual URLs. Examples of a request 
including address identifiers include a new information 
request to a network server or a request to retrieve email. 
Upon receiving such a request, the actual URLs are retrieved 
by the account manager from an address table in the link 
server. At 968, the original requests from the mobile device 
are modified to produce updated requests with the actual 
URLs substituted and the updated requests are then sent to 
the identified network servers) corresponding to the URLs 
at 970. 

FIGS. 9E to 9G constitute a process flow diagram of the 
mobile device, which corresponds to processes in the fink 
server. At 953, the mobile device exchanges information 
with the link device to establish a communication session. 
The request to establish a communication session can also 
be initiated from the mobile device by sending a message to 
the link server. Besides a device identification of the mobile 
device, the message includes a URL of the link server. To 
establish the communication session, device characteristics 
information is released to the link server. Such characteris- 
tics information may include the size and type of the display 
screen of the mobile device. After the communication ses- 
sion is established, the interface engine works at 957 with 
the control engine in the link server. 

At 959, the client module in the mobile device receives a 
message. Typically the mobile device receives three kinds of 
messages: notifications, SDD files and local service 
requests. At 963, a notification message arrives. Note that a 
notification message received at the mobile device is differ- 
ent from the notification or alert message provided from a 
network server. The notification message received at the 
mobile device is a distilled version with no explicit URLs. 
Upon receiving the notification message, the client module 
looks up in an alert list in the mobile device to determine if 
there is an identical notification pending there at 965. 
Sometimes a user of the mobile device may not necessarily 
or immediately respond to an alert, the mobile device hence 
maintains an alert list to keep all the received notification or 
alerts. If a notification identical to the newly received 
notification message is found, the alert list gets updated with 
the newly arrived notification message at 967. Otherwise, 
i.e., no identical notification message is found in the alert 
list, the newly arrived notification message is added sequen- 
tially into the alert list at 969. Meanwhile, the user is notified 
according to the alert type in the received notification 
message at 971, When the user decides to respond to the 
notification and presses a key or activates a soft key, a 
request corresponding to the notification message is sent to 
the link server at 973. 

At 975, a message is received requesting an update to the 
local services in the mobile device. Local services may 
include functions for modifying wireless voice/date 
protocols, configuration or system parameters, bookmarks, 
addresses, subscriber provisioning information and other 
parameters that may enable or disable certain telephony and 
data features of the mobile devices. Technically, the inter- 
face engine recognizes such a message by a special prefix 
indicating a "local service" request. According to one 
embodiment, a URL for a local service always begins with 
"device:", (e.g., device :addressbook). 
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Upon the arrival of a local service request, the local 
service in the mobile device is invoked. For example, a user 
may navigate to a page providing email service to the mobile 
device. After a key is pressed or a soft key is activated, a 
request is sent to the control engine of a link server, which 5 
in turn responds by a local service request which causes an 
address book to be displayed in the mobile device. After the 
user makes a selection from the address book, at 977, the 
mobile device sends another request specifying the selected 
address to the control engine which then sends the mobile 1Q 
device an SSD file. Upon receiving the SSD file, the display 
screen displays a page which allows the user to proceed with 
composing a mail message. 

At 981, when the received message is an SDD file. Upon 
receiving the SDD file, the interface engine renders the SDD 
file and causes the display screen of the mobile device to 15 
display according to the SDD file at 983. Within the display 
screen, the user may browse the screen display at 985 by 
pressing a navigation key to reposition a cursor to a subject 
of interest. For further information on the selected subject, 
the user may press a> predefined key; hence a URL request 20 
is generated at 987. Also at 985, the user may be asked for 
input data to some context. Once the input data is entered, 
the user may press a predefined key, such as the "OK" key 
to generate a URL request at 987. The URL request is then 
sent to the link server for processing at 989. 25 

The present invention is described above by way of 
example using specific embodiments. Numerous changes 
and modifications can be made within the scope of the 
invention claimed below. 

What is claimed is: 30 

1. A method for an interactive two-way communication 
mobile device of a* wireless network to interact with a 
network server, the mobile device having a display screen, 
the method comprising: 

initiating a control engine in a link server device coupled 35 
to a landnet after the mobile device establishes a 
communication session with the link server device over 
the wireless network, through a pair of first and second 
protocol interfaces, the first protocol interface residing 
in the mobile device and the second protocol interface 40 
residing in the link server device, the link server device 
comprising: 

an account manager managing a user account of the 

mobile device; and, 
a message processor receiving a message from the 45 

network server over the landnet; 
associating the control engine with an interface engine 
operating in the mobile device corresponding to the 
user account, and 
converting the message by the message processor to a 50 
compact data file that can be efficiently transportable in 
the wireless network, including substituting a uniform 
resource identifier in the message with a corresponding 
address identifier while maintaining the uniform 
resource identifier in the link server device. 55 

2. The method as recited in claim 1, wherein the message 
received from the network server represents a World Wide 
Web page. 

3. The method as recited in claim 2, the method further 
comprising forwarding device characteristics information of 60 
the display screen from the mobile device to the link server 
device over the wireless network. 

4. The method as recited in claim 3, wherein the compact 
data file is screen description data that can be directly 
rendered by the interface engine in the mobile device. 65 

5. The method as recited in claim 4; wherein the message 
comprises a device identifier identifying the mobile device. 
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6. The method as recited in claim 4; the method further 
comprising buffering the message in a cache memory in 
reference to the user account of the mobile device in the link 
server device. 

7. The method as recited in claim 6; wherein said con- 
verting the message by the message processor to a compact 
data file comprises converting the message to the screen 
description data corresponding to the device characteristics 
information received from the mobile device. 

8. The method as recited in claim 7; the method further 
comprising causing the display screen by the interface 
engine, upon receiving the screen description data, to dis- 
play the contents in the message from the network server 
according to the screen description data from the link server 
device. 

9. The method as recited in claim 8, the method still 
further comprising: 

navigating in the contents being displayed on the display 

screen of the mobile device; 
generating a client request by a client module in the 

mobile device; and 
sending the client request to the link server device over 

the wireless network; and 
forwarding the client request to the network server over 

the landnet. 

10. The method as recited in claim 9, wherein said 
generating a client request comprising making a selection in 
the contents by activating a predefined key. 

11. The method as recited in claim 9, wherein said 
generating a client request comprising receiving inputs from 
a user by using an limited input interface of the mobile 
device. 

12. The method as recited in claim 11, wherein the limited 
input interface comprises a phone keypad equipped in the 
mobile device. 

13. The method as recited in claim 11, wherein the limited 
input interface comprises a number of soft keys displayed on 
the display screen of the mobile device. 

14. The method as recited in claim 6; wherein said 
converting the message by the message processor to a 
compact data file comprises: 

generating the screen description data from the message 
with the corresponding address identifier. 

15. The method as recited in claim 14; wherein said 
substituting the uniform resource identifier comprises stor- 
ing the uniform resource identifier in an address table 
managed by the account manager in the link server device. 

16. The method as recited in claim 15; the method further 
comprising causing the interface engine, upon receiving the 
screen description data, to display on the display screen 
contents in the message from the network server according 
to the screen description data from the link server device. 

17. The method as recited in claim 16, the method still 
further comprising: 

navigating in the contents being displayed on the display 

screen of the mobile device; 
generating a client request by a client module in the 

mobile device; and 
sending the client request to the fink server device over 

the wireless network. 

18. The method as recited in claim 17, wherein said 
generating a client request comprises: 

making a selection in the contents by activating a pre- 
defined key, the selection linking to the address iden- 
tifier; and 

forwarding the client request to the network server over 
the landnet. 
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19. The method as recited in claim 18; further comprising: 
looking up the address table for the address identifier; 
replacing the address identifier with the uniform resource 

identifier from the address table; 
forming a new client request in the link server device; and 
sending the new client request to the network server over 

the landnet. 

20. The method as recited in claim 17; wherein said 
generating a client request comprises receiving inputs from 
a user using a phone keypad of the mobile device. 

21. The method as recited in claim 20; the method still 
further comprising: 

substituting variables in the message with the inputs in the 
link server device to produce an updated message; ^ 

converting the updated message to an updated screen 
description data corresponding to the device character- 
istics information received from the mobile device; and 

sending the updated screen description data to the mobile 
device over the wireless network. 20 

22. The method as recited in claim 1, wherein the message 
received from the network server is a markup language file. 

23. The method as recited in claim 22, wherein the 
markup language is selected from a group consisting of 
Handheld Device Markup Language (HDML), HyperText 25 
Markup Language (HTML), Wireless Markup Language 
(WML), Standard Generalized Markup Language (SGML) 
and Extensible Markup Language (XML). 

24. The method as recited in claim 1; wherein the message 
received from the network server is a notification compris- 30 
ing a device identifier identifying the mobile device by the 
account manager and a universal resource identifier identi- 
fying a service web site. 

25. The method as recited in claim 24; wherein said 
converting the message by the message processor to a 35 
compact data file comprises: 

looking up in a notification list managed by the account 
manager for an entry substantially equivalent to the 
received notification in the fink server device; 

updating the notification list with the received notifica- 40 
tion; 

substituting the uniform resource identifier with a corre- 
sponding address identifier; 

storing the uniform resource identifier and the corre- 45 
sponding address identifier in an address table managed 
by the account manager in the link server device; and 

converting the notification with the uniform resource 
identifier substituted by the address identifier to the 
compact data file, 50 

26. The method as recited in claim 25; wherein said 
updating the notification list comprises: 

replacing an entry with the received notification if the 
entry is identical to the received notification in the 
notification list; and 55 
inserting the received notification into the notification list 
if there are no entries that are identical to the received 
notification in the notification list; 
wherein the inserted received notification is sequenced in the 
notification list. 60 

27. The method as recited in claim 26; the method further 
comprising: 

processing a client request by the control engine to form 
an updated client request in the link server device upon 
receiving the client request from the mobile device that 65 
responds to the received notification from the link 
server device; and 



forwarding the updated client request to the network 
server. 

28. The method as recited in claim 27; wherein said 
processing a client request by the control engine comprises: 

retrieving the uniform resource identifier from the address 
table with respect to the corresponding address identi- 
fier; and 

generating the updated client request with the uniform 
resource identifier therein. 

29. A method for an interactive two-way communication 
mobile device of a wireless network to interact with a 
network server, the mobile device having a display screen, 
the method comprising: 

establishing a communication session between the mobile 
device and a link server device over the wireless 
network through a pair of first and second protocol 
interfaces, the first protocol interface residing in the 
mobile device and the second protocol interface resid- 
ing in the link server device, the link server device 
coupled to the network server through a landnet, so that 
the mobile device interacts with the network server via 
the link server device: 

associating an interface engine operating in the mobile 
device with a control engine operating in the link server 
device with respect to an account established for the 
mobile device in the link server device; 

receiving a compact data file generated in the link server 
device over the wireless network, the compact data file 
having been generated by the link server device by 
substituting a uniform resource identifier in the mes- 
sage with a corresponding address identifier while 
maintaining the uniform resource identifier in the link 
server device; and 

rendering the compact data file by the interface engine to 
display contents of the compact data file. 

30. The method as recited in claim 29, wherein said 
establishing a communication session comprises forwarding 
device characteristics information of the display screen of 
the mobile device to the link server device over the wireless 
network. 

31. The method as recited in claim 30, wherein the 
compact data file is screen description data converted by a 
message processor in the link server device from a message 
received from the network server, the message representing 
a World Wide Web page. 

32. The method as recited in claim 31, wherein the World 
Wide Web page is represented in a markup language. 

33. The method as recited in claim 32, wherein the 
markup language is selected from a group consisting of 
Handheld Device Markup Language (HDML), HyperText 
Markup Language (HTML), Wireless Markup Language 
(WML), Standard Generalized Markup Language (SGML) 
and Extensible Markup Language (XML). 

34. The method as recited in claim 31, wherein the 
message processor determines whether there are uniform 
resource identifiers in the message. 

35. The method as recited in claim 34, wherein the 
message processor substitutes the uniform resource identi- 
fiers with respective address identifiers if there are uniform 
resource identifiers in the message; the uniform resource 
identifiers associated respectively with the address identifi- 
ers maintained in an address table in the link server device. 

36. The method as recited in claim 35, wherein the screen 
description data comprises the address identifiers. 

37. The method as recited in claim 36, the method further 
comprising: 
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navigating in the contents being displayed on the display 

screen of the mobile device; 
generating a client request by a client module in the 

mobile device; the client request comprising one of the 

address identifiers; and 5 
sending the client request to the link server device over 

the wireless network. 

38. The method as recited in claim 37, wherein said 
generating a client request comprises: 

making a selection in the contents by activating a pre- 
defined key on the mobile device. 

39. The method as recited in claim 38, wherein the 
predefined key is in a phone keypad equipped in the mobile 
device, 1S 

40. The method as recited in claim 38, wherein the 
predefined key is a soft key display in the screen display of 
the mobile device. 

41. The method as recited in claim 37, wherein the control 
engine in the link server device retrieves one of the uniform 2Q 
resource identifiers from the address table with respect to the 
one of the address identifiers in the received client request 
and generates an updated client request with the one of the 
uniform resource identifiers therein, the updated client 
request subsequently forwarded to the network server. 25 

42. The method as recited in claim 31, wherein the 
message processor interprets the message to generate the 
screen description data according to the device characteris- 
tics information. 

43. The method as recited in claim 29, wherein the 3Q 
compact data file is an updated notification processed in the 
link server device from the notification received from the 
network server, the notification comprising an alert type and 

a uniform resource identifier. 

44. The method as recited in claim 43, wherein the 35 
updated notification comprises an address identifier corre- 
sponding to the uniform resource identifier in the 
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notification, the uniform resource identifier associated with 
the address identifier maintained in an address table in the 
link server device. 

45. The method as recited in claim 44, the method further 
comprising notifying the user of the updated notification 
according to the alert type when the mobile device receives 
the updated notification. 

46. The method as recited in claim 44, the method further 
comprising updating an alert list with the received updated 
notification in the mobile device. 

47. The method as recited in claim 46, wherein said 
updating an alert list comprises: 

replacing an entry with the received updated notification 
if the entry is identical to the received updated notifi- 
cation in the alert list; and 
inserting the received updated notification into the alert 
list if there are no any entries identical to the received 
updated notification in the alert list; 
wherein the inserted received updated notification is 
sequenced in the alert list. 

48. The method as recited in claim 29, wherein the 
compact data file is a service request comprising a special 
identifier before an address, the address identifying a local 
service offered in the mobile device. 

49. The method as recited in claim 48, the method further 
comprising: 

invoking the local service in the mobile device upon 
receiving the service request from the link server 
device; 

sending a client request to the link server device over the 
wireless network in response to the local service; and 

receiving screen description data generated in the link 
server device with respect to the client request. 

* * * * * 
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